Ask Me Anything with Daniel Maconaghie, Automation Practice Lead @ Tower Insurance

A leader in strategy and tech innovation at Tower Insurance, Daniel Maconaghie is an expert at identifying and deploying technologies that deliver huge operational expense and efficiency wins. Daniel has led his team in re-imagining their approach to put digital first, and by doing so deepening their customer relationships and business efficacy.

Fun fact: Daniel is famous at Ushur for achieving one of the quickest Ushur use case deployments to date. His team identified a use case, built, and tested their Ushur in about 2 hours - a true testament to his ability to solve problems alongside his team automation gurus!

We are thrilled to have Daniel here to answer all your questions about identifying automation projects and delivery strategy!

How to participate in the AMA:

  1. Ask your question in this thread any time from now until December 9.
  2. Ensure you get updates on this topic by clicking the ‘Watching’ button below.
  3. On December 9, Daniel will begin answering all of your questions! You’ll receive an email update when he replies.

Tower Insurance is headquartered in Auckland, New Zealand and is a large property and casualty insurer operating in New Zealand and the Pacific Islands. Read more about the challenges they’ve solved using Ushur here.

2 Likes

What was your biggest challenge in having the business build deploy their own processes?

2 Likes

Hey Daniel! One of the biggest challenges in automation deployment is the handling of legacy systems already in place. Have you ever had a situation with folks preferring to continue following the conventional methodologies as long as the outcome is good at the end of the day? If so how did you or would have handled it?

2 Likes

Glad to have you here Daniel, here is my questions :slight_smile:

When it comes to trying innovative, quick-to-deploy solutions in your organization, what impact have you seen in the culture and mindset of your team so that they seek new solutions for day-to-day challenges?

From my perspective, I’m talking to lots of prospects and customers and sometimes I feel the prospect is far from this mindset of “let’s try to do things differently” or “it’s ok if it doesn’t work as long as it is quick and requires the least amount of efforts” or “let’s start small and grow rather than trying to boil the ocean”.

3 Likes

Hi Daniel!

Playing off John’s question, what has been your biggest opportunity in having the business build and deploy their own processes?

1 Like

Definitely the biggest challenge was ensuring that the guardrails we put in place were safe & secure without stifling the creativity and passion of the Citizen Developers by being too restrictive. It was something that evolved a lot over our early use-cases to where it is today and I believe the success we’ve had with that was ensuring that any processes introduced would support and empower our culture, not strangle it.

Aside from working with right IT teams early on to ensure all the boxes were ticked from a platform perspective, we needed to have processes in place for each use-case that could potentially be deployed.

On the Technology side, from our experience, we knew early on what these processes would need to address and roughly how that would look. The important part though was taking the Citizen Developers on the journey with us.

Quite often as individuals we can take for granted the journey we go through to become proficient at something to the level of where it is “second nature”. Being aware of this fact with respect to IT Best Practices was crucially important for ensuring that we were having meaningful conversations with the Citizen Devs. We didn’t want to end up with “just do x, y & z” we wanted to start the problems that x, y & z were created to solve and then go on that journey and arrive at the same conclusions together. This also had the added bonus of building rapport amongst the team, which is an added win.

As we scaled up over time we then leveraged these initial Citizen Devs to train, guide and support the next wave of Citizen Devs. Since they had been on the journey themselves and understood the ‘why’, they were empowered now to take others on that same journey of understanding.

7 Likes

Hi Cameron, I personally haven’t seen that problem so maybe we’re just lucky, haha!

On a serious note, that kind of situation sounds like an engagement problem. What I would do in that situation would be first seek to understand from the person(s) who are continuing the ‘old’ way, to really get a feel for the possible reasons;

Are they properly trained on the new method/system?
Do they understand the ‘why’? (as mentioned in my other response to John)
Are they even aware of it all?
Did we miss overlook something in the old way than can’t be done with the new way?

We can’t have a flow diagram for every possible reason that could occur, but one of the strongest things we can do is leverage a peer network. If you’re running a Citizen Developer program, or any training program for that matter, you can quickly identify the individuals who are embracing it and are passionate about it. Enabling these individuals to share and work with others was the easiest way we found to raise engagement with any new platform/tool/process, it was also one of the best ways we would find potential issues.

I tend to describe this kind of engagement spread as ‘viral’ - even if you don’t run any active change campaigns (you should), it will still spread (in a good way!)

6 Likes

Thanks Amir, glad to be here :slight_smile:

I think the biggest shift that we had to go through culture wise, was re-defining what “success” was. In traditional software development you tend to build and ship, then perform multiple iterations/releases on top of that. The ‘success’ factors here tend to stem from the shipping the product (e.g. the first release/feature), alongside measurements of quality/engagement.

We took a slightly different approach - more in line with the principles of Lean Delivery, with ideas stemming from Eric Ries’s book The Learn Startup. Our success wasn’t defined by shipping a particular engagement to our Customers, or on how successful that engagement was.

It was more along the lines of “We think xyz might work, lets test that idea” and much like the famous Edison quote we didn’t consider failure if the idea didn’t work. We instead put emphasis on how many or how often we could experiment with different ideas in a safe way with a small amount of customers. When we found something that would stick (e.g. high engagement) then we would shift effort into fleshing that out more. It’s important to note that we had business SME’s working extremely closely with us on any particular initiative. Of course, you have to have the right type of work environment and senior leadership buy-in to support a culture like that, and we did.

I think a tell tale sign that a team is working in this fashion is by listening to the day-to-day conversations. You hear less restrictive-based sentences starting like “That will be too hard” or “We don’t do it that way” to more exploratory based ones like “I wonder if” or “let’s try this”.

6 Likes

Hi Daniel, Thanks for making time for this AMA.

What have been the challenges, pitfalls integrating new solutions with existing ones, especially navigating with IT and security?

1 Like

Hi Janeen, I should have read further down the list, I would have saved part of my answer to John for this question, haha.

It has to be the fact that since they are a part of what is ‘happening’ rather than having it ‘happen to’ them, it makes it so easy to get further buy-in with the ‘viral’ type engagement that I mentioned before. Business users and experts are seeing what their colleagues are doing and are actively seeking us out with their own ideas.

4 Likes

Thank you Daniel. That was insightful because one of the challenges in putting together a program of technology adoption is where to start. Guardrails not only provide the safety and security but also provide a structure to encourage that adoption. That “where do I start”. Great stuff!

2 Likes

HI Daniel. I was going to asking you a question about benefits measurement and management but reading your answers to other question I’m glad to see your emphasis on taking lean, experimental approaches to solve problems and that senior leadership buy-in and support is vital for succeeding.

In our organisation I’m happy to say that we have senior leadership buy-in and support and we’re working hard to evolve our culture into something more lean and agile but we can often fall back into traditional ways of working and reporting– for example - business case development, declaring expected “benefits” before we implement.

So, my question: Do you have any tips on how to sustain the buy-in from senior leadership? For example, how do you keep them involved? How do you communicate success and failure? How do you ensure that benefits are sustained? Thank you.

6 Likes

Thanks for the reply Daniel!
I like how you described enabling advocates to connect with others on the team as a “viral spread”. Positivity and good impressions are always contagious!

2 Likes

Hi Barry, those are great questions!

I think this is something that we could have a chat about sometime, I’m very interested to hear your insights too as I think it can be a deep topic.

When it comes to communicating success or failures we usually just take a very straight-forward transparent approach, but as I mentioned before I think an important aspect of this is emphasizing the narrative of experimentation - this is well understood amongst our senior leadership as we liken it to feature development on a traditional website which they have had a lot of exposure to (e.g. they understand the concept of A/B tests).

Sustaining benefits is something that we’ve been focusing on now as enough time has passed so that the ‘hype’ phase is over and we’re really trying to push for increased growth in terms of micro-engagement executions. We are heavily leveraging the divisional leaders amongst the business to do this, it makes it a lot easier when they can see that their team members are empowered (via the no/low-code platform) to be an actual part of the delivery team. We push that narrative a lot - that we provide the platform and give them the agency to experiment as much as they want in the ‘sandbox’ (with help as needed of course). I think this naturally “bubbles up” to the Senior Leadership of those divisions as not only a great engagement story, but also enabling them to get the current facts/state-of-play directly from someone in their division who is an actual part of the delivery team.

Again, would love to chat further with you on this!

1 Like

thanks Daniel, that’s a very helpful response. I’d definitely be interested in chatting further on this. cheers.

Thank you all for participating in this Ask Me Anything - and an extra big thanks to this month’s expert, Daniel! This thread will now be locked, but feel free to start a new topic in the discussion forums to continue the conversation.

Stay tuned for more AMAs coming in the new year!